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1. INTRODUCTION 
1.1 SCOPE 

The objective of this document is specifying a method for enabling dynamic bandwidth 
utilization in an ATM network based on detecting which time slots of a given TDM trunk 
are active and which are inactive. When an inactive state is detected in a specific time 
slot, the time slot is dropped from the next ATM structure and the bandwidth it was 
using may be reutilized for other services. This method may be applied utilizing any 
method of time slot activity detection, e.g., CAS, CCS. There is an informative section 
at the end of the specifications which addresses some ways of time slot activity 
detection. The specific implementation and method(s) chosen by individual 
implementors for activity detection is beyond the scope of this document. The 
specifications in this document are applicable in both PVC and SVC ATM network 
configurations without the need to create any special signaling messages/elements. 
The transport of the active time slots using this specification utilizes the standardized 
CES Structured DS1/E1 Nx64 kbits/s Service defined in ATM Forum Document af- 
vtoa-0078.000 Section 2. 



1.2 REFERENCE CONFIGURATION 
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DSS = Dynamic Structure Sizing 
DBU = Dynamic Bandwidth Utilization 

Figure 1.1 Reference Configuration for Trunking with Dynamic 

Bandwidth Utilization 
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FinnrP 1 1 depicts a reference configuration for a generic application of this 
ri&um arts Scat!ons The ATM nettvork element shown may be a physica or a 
^^er^^^WeTseveral interfaces to users as well as to other ne work 
elements Included in this element is the circuit emulation interwork.ng funct.on (CES 
IWF) which is the subject of this document's specifications. 
This interworking function performs the following functions 

. Circuit Emulation Services (CES) Structured DS1/E1 Nx64 kbits/s Service per 
ATM Forum af-vtoa-0078.000 Section 2 

• Time slot activity detection 

. Dynamic Structure Sizing (DSS) of the AAL1 structure which correlates with 

the active time slots in the TDM to ATM direction 
. Recovering the active time slots from the AAL1 st ructure ir .the ATM to TDM 

direction, and placing them in the proper slots in the TDM stream 
. Placing the proper signals (e.g., ABCD) in each of the time slots of the 

recovered TDM stream 
ThP function shown as ATM Queue with DBU in the diagram represents the ATM 

are expanded in a later section. 

1.3 DEFINITION OF TERMS 

The following definitions are applicable to the text used in the entire specification that 
follow. 

1.3.1 dynamic Structure Sizing (DSS) 

The ability of a CES interworking function to dynamically adjust the size .of the > AAL1 
structure V Tor down based on the number of active time slots contained I . n the Dl S /E1 
KSl^ngdrcuft emulation. The structure has a maximum size, defined below, 
which is set at the time of configuring the IWF. 
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1.3.2 Configured Structure 

This is the maximum size AAL1 structure when all provisioned (assigned) time 
slots of a given trunk are active. This is pre-determined by the maximum number 
N of the 64Kbps time slots provisioned on the trunk at the time of configuring the IWF. 
N may represent a full or a fractional DS1 or E1 frame. As an example, a full DS1 has 
a configured structure that accommodates the contents of 24 time slots (N=24) which 
corresponds to a (maximum) pay load of 576 octets of user information and 12 octets 
signaling in the case of CAS (see Figure 3.1 below). Another example is a fractional 
DS1/E1 trunk utilizing only 4x64K time slots. In this case the configured structure 
accommodates the contents of only 4 time slots (N=4) which corresponds to a 
(maximum) payload of 96 octets of user information and 2 octets signaling in the case 
of CAS. The order and position of the assigned time slots in the DS1/E1 frame is 
configured at the user's discretion and is accommodated via a bit mask as explained 
below. 



1.3.3 Active Structure 

This is the AAL1 structure containing the information from actually active time slots at 
any given instance. Inactive time slots are not mapped into the AAL1 structure 
altogether. There are two types of active structure described below: 

• Active Structure Typel: is an Active Structure which contains a 
Bitmask. 

• Active Structure Type2: is an Active Structure which does not 
contain a Bitmask. 

The bit mask is usually transmitted only in structures containing a pointer (the only 
exception is when transitioning from all inactive slots to at least one active slot in which 
case there may be one structure with a bit mask that does not have a pointer). This 
approach minimizes the bandwidth consumption (less frequent bit mask transmission) 
and provides deterministic location of the bit mask after the pointer. 



1.3.4 Inactive Structure 

This is a structure of 1 to 4 octets long transmitted when all time slots are inactive. It 
contains only a bit mask full of zeros, with a parity bit of value 1, and no payload nor 
signaling substructure. Detailed specifications are stated in the sections to follow. 

1.3.5 BITMASK 

This is a bitmask that indicates the activity status of the provisioned (assigned) N time 
slots. This bit mask is always created by the ATM transmitter and enclosed in the 
AAL1 structure, as explained in the specifications, to enable the ATM receiver to 
correctly place the retrieved time slots in the DS1/E1 frame which it reconstructs. The 
format of the bitmask, which includes a parity bit, and how it is applied are described in 
Sections 3 and 4 below. 
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2. INTERWORKING FUNCTION (IWF) REQUIREMENTS 

Following are the requirements of the IWF to conform to this specification, indicated by 
an "R." 

(R) The IWF Shall be capable of performing the CES functions per Circuit 
Emulation Services CES Structured DS1/E1 Nx64 kbits/s Service specification 
af-vtoa-0078.000 Section 2 

(R) The IWF Shall be capable of performing activity detection based on CAS, CCS 
or any other method chosen by the implementor. An informative section, 
Annex A, is included below to help implementors with this function. 

(R) The IWF Shall be capable of performing all the required functions described in 
this document using the formats and procedures stated in the following 
sections with the exception of Annex A, which is Informative. Optional 
functions, indicated with an "O" may be implemented at the .option of the 
implementor. Conditional Requirements, indicated with a CR are required 
when an associated Option is implemented. 

(O) The use of BISDN signaling (UNI 3.1 or equivalent) for supporting SVCs in the 
IWFs is Optional. 

2.1. Configuration of the Time Slots in the IWF 

At the time of configuring the IWF, the number and order of the Configured structure 
time slots is determined by the user and must be matched between the two IWFs al the 
ends of the virtual connection. Using the example of a configured s ructure of 4 tone 
slots the user may choose to assign different time slots in the two ends of the 
connecVion. For example, he may choose time slots 1 to 4 fei .the 'transmitting end of 
the connection (TDM to ATM direction at the source) and time slots 6 to 10 in the 
receiving end of the connection (ATM to TDM direction at the destination), 
ft is essential to understand this process because the bitmask indites only the 
numerical order of the assigned time slots in the > Configured Structure and not the 
absolute time slot position in the 24 slots of the DS1 or the 30 slots of the E1 frame. 
This is not an additional requirement beyond the original CES specifications (af-vtoa- 
0078.000), it is simply a clarification. 

3. SPECIFICATION OF THE ACTIVE AND INACTIVE STRUCTURES 

As stated in Section 1.3.3 above, the active structure has two types: Active Structure 
Type 1 (with Bitmask) and Active Structure Type 2 (without Bitmask). 
Figure 3.1 below shows the two types of active structure for the case of DS1/E1 frames 
utilizing CAS (Channel Associated Signaling). Figure 3.2 shows the same for the 
case of DS1/E1 using CCS (Common Channel Signaling). It should be noted that 
there ?s no limitation on the use of Super Frame or Extended Super Frame structures 
per the CES specification document as illustrated in Figure 3.1. 
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Bit Mask Substructure 

1 -4 Octets for DS1 , 1 -4 for E1 



Payload Substructure 
(One ESF or Two SFs) 

24 to 576 Octets for DS1 
or 

16 to 480 Octets for E1 



ABCD Signaling Substructure 
for ESF, or AB/A'B' for SF 

1 to 12 Octets for DS1 
or 1 to 15 for E1 



Figure 3.1a CES with CAS 
Active Structure Type 1 (with Bitmask) 



Payload Substructure 
(One ESF or Two SFs) 

24 to 576 Octets for DS1 
or 

16 to 480 Octets for E1 



ABCD Signaling Substructure 
for ESF, or AB/A'B' for SF 

1 to 12 Octets for DS1 
or 1 to 15forE1 



Figure 3.1b CES with CAS 
Active Structure Type 2 (without Bitmask) 



Bit Mask Substructure 

1 -4 Octets for DS1 , 1 -4 for E1 



Payload Substructure 
(One Frame) 

1 to 24 Octets for DS1 
or 

1 to 31 Octets for E1 



Figure 3.2a CES with CCS 
Active Structure Type 1 (with Bitmask) 



Payload Substructure 
(One Frame) 

1 to 24 Octets for DS1 
or 

1 to 31 Octets for E1 



Figure 3.2b CES with CCS 
Active Structure Type 2 (without Bitmask) 
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3.1. ACTIVE STRUCTURE TYPE 1 (WITH BlTMASK) 

Active Structure Type 1 , With Bitmask, Shall be formatted as shown in Figure 3.1a. 
In order to assure that the location of the bitmask within the str ucture i is de >ter min istic 
coSlent and simple to find, the following requirement must be met when the IWF 
formats active structures type 1 with bit mask. 

(R) Whenever an Active Structure Type 1 , which Shall 'always start with i a bil t mask 
1 ' is used, a Structure Pointer Shall always be used 

the Structure except in the following condition. T he j' st Active Structure 
followinq an Inactive Structure (transition from all inactive time slots to at least 
one aSPve time slot) May Not have a pointer. See requirement for frequency of 
transmitting this type structure in Section 4.2 below. 
This requirement is illustrated in Figure 3.3. As shown the pointer points to the 
beginning of the bitmask which is the first field in the new structure. 



Pointer Bitmask 

_\ 7 

P | Last Structure - -| f- j- ► | ' | Type 1 Payload | 

A Ji New Active 
Structure 

Cell+AALl _ ^T l- _ JT T^J Type 1 

Headers Boundary 

Figure 3.3 Illustration of the Beginning of a Type 1 Active Structure 

Note that AAL1 structure pointers will be utilized f n D j^^ 
when the number of configured channels is equal to one. (The CES s P ec, lL ca "°" 
defines that theN=1 case in basic service mode would not use pointers.) This 
Squired by t£ DBCES^WF in order to allow the indication of an active structure with 
bitmask once every eight cells, even when N is equal to one. 
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3.1.1 Bitmask Format 

(R) The Bitmask Shall be one to four octet(s) long depending on the number of 
assigned time slots corresponding to the configured structure. Note that a 
single parity bit Must always be included in the bit mask following the bit 
representing the highest order time slot (see Figure 3.4). For 1 to 7 assigned 
time slots, the bitmask Shall be one octet. For 8 to 15 assigned time slots, the 
bitmask Shall be two octets. For 16 to 23 assigned time slots, the bitmask 
Shall be 3 octets. The bitmask Shall be 4 octets for 24 (full DS1 frame) to 31 
(full E1 frame) assigned time slots. 

(R) The number of bits used in a bitmask Shall be equal to the number of 
assigned time slots (N) in the configured structure with one bit correlating to 
each assigned time slot, plus one bit for the parity error check, following the 
format specified below. All unused bits in the bitmask Shall be set to zero. 

(R) The Bitmask bit assignment Shall be as illustrated in Figure 3.4 and explained 
as follows. The first bit (LSB) indicates the activity status of the first assigned 
time slot in the configured structure. This is the time slot which has the lowest 
numerical order among all assigned time slots in the configured structure. The 
second bit (next to LSB) in the bitmask indicates the activity status of the 
second assigned time slot (which has the next numerical order higher than the 
first slot's), and so on. The most significant bit in the bit mask (the highest 
numerical order bit in the highest numerical order octet) correlates to the 
highest numerical order assigned time slot. 

(R) The bitmask represents the relative position (numerical order) of the assigned 
time slots in the configured structure. This requirement is based on the fact that 
the assignment of time slots is not required to be the same on the transmitting 
and receiving ends of a virtual connection. 

(R) A bit value of (logical) one indicates the corresponding time slot is active, a 
zero value indicates inactive time slot 

(R) An odd parity bit shall be used for error protection of the bit mask. The parity bit 
shall be located at the end of the bit mask in bit n+1 ; where bit n corresponds to 
the highest order time slot in the configured structure (see Figure 3.4 for bit 
order). 

(R) When the error protection field of the bit mask indicates an error, the receiver 
Shall use the previously received correct bit mask instead of the current one. 

(R) When an error is detected in the bit mask, CAS signaling Shall Not be updated 
in the corresponding time slots until the receiver has received a valid bit mask. 
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MSB 
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1 



First 
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— i 1 1 1 r 
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I 



I 



Highest \ 
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Timft Rim 



Lowest 
Order 
Assigned 
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1 



Parity Bit 
for 8 Assigned 
Time Slots 



Parity Bit for Maximum Possible number 
of Assigned Time Slots (Full E1) 

Figure 3.4 Bitmask Format 

3.1.2 Payload and Signaling Substructures 

The Payload and Signaling Substructures Shall be formatted as defined in the current 
ATM Forum CES Structured DS1/E1 Nx64 kbits/s Service specifications in af-vtoa- 
0J78.0S0 SectTon 2. The primary difference between i af-vtoa-007a £00 and this 
specification is that the payload and signaling in this specification are only made up of 
2S£^*£m? ?n a L other twS specifications they may be all active a mix d 
active/inactive or all inactive. Nevertheless, the formats are all the same In th s 
spScation, if no time slots are active, the Payload and S.gnal.ng Substructures are 
empty (see the "All inactive Time Slots" section below). 

3.2. ACTIVE STRUCTURE TYPE 2 (WITHOUT BlTMASK) 

(R) This type structure Shall be formatted as shown in Figure 3.1b. 
The difference between this structure and a Type 1 (Active Structure With Bitmask) is 
the absence of the bitmask and the AAL1 structure pointer. 

(R) This type structure Shall be used only when an AAL1 structure pointer is not 
used 



3.2.1 Payload and Signaling Substructures 

The payload and signaling substructures are identical to the substructures described 
in Section 3.1 .2 above. 
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3.3 Inactive Structure 

(R) This structure Shall be one to 4 octets as described in the bit mask 
requirements in Section 3.1.1. All bits except the N+1 bit SA7a// be set to zero. 
The N+1 bit is the parity bit and Shall be of value 1 for correct structure. N is 
the number of assigned time slots in the subject VC, i.e., the maximum number 
of time slots that can be active on this VC. See Figure 3.4 for format. 

(R) This type structure Shall be used only when all assigned time slots are 
inactive. 



4. PROCEDURES 

Note that in the following text Transmitter refers to the IWF transmitting into the ATM 
network and Receiver refers to the IWF receiving from the ATM network. This entire 
section is normative. 

4.1. Configuration 

Each IWF Shall be configured by assigning specific time slots corresponding to each 
virtual connection in each direction of transmission. This is the Nx64 K bandwidth 
defined in Section 2 of the af-vtoa-0078.000 specification. This may be the full 
DS1/E1 line or a fraction thereof. 

In addition, the following parameters (which are beyond the scope of this specification) 
must be configured for each time slot for proper operations: 

• Definition of the signaling bit combinations, in both directions, that constitute 
idle, not idle, and blocking States. 

• Idle code to be inserted on the receive side (when the slot has not been 
transmitted due to being inactive on the transmit side) 

In full duplex connections both directions contain the same number of assigned time 
slots (Nx64), but generally different time slot positions in the DS1/E1 frame. The 
following procedures address one direction of transmission. The procedures for the 
other direction are identical. 
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S^c 



4.2. Transmitter 

The transmitting IWF determines each time slot's activity status from the information 
JeceiveS from both the local and remote DS1/E1 equipment in > the s.gna.ng bits 
eS to ST time slot. The transmitting IWF Shall then format the ™M ^hme 
slots into one of the two AAL1 structure types discussed in Sections 3.1 and 3.2 above 
AUhe beginning of transmission from a quiescent state, or whenever the number of 
active time slots changes, an Active Structure with Bitmask (Type 1) Shall be 
fransmSaUhe next ava able opportunity. From a quiescent (inact.ve) state this is 
th?S^OTitedcell. Periodic use of Type 1 active structure, which contains a 
pointer is requ fed to assure proper structure alignment in the receiver To comply 
5?Jm>T Recommendation 1.363-1, which requires transmission of one structure with 
a pointer every 8 cells, the following requirements apply. 
(R) The following two requirements Shall be met whenever there is any 'number ■of 
( active time slots of 1 1 to N. N is the maximum number of conf.gured time slots 

as described in Sections 1.3.2 and 2.1. 
(R) A structure pointer Shall be transmitted every 8 cells. An Active Structure 
Type? with bit mask Shall be transmitted for every structure pointer that is not a 
dummy pointer. 

(R) An active structure Type 2 (without bitmask ) Shall be transmitted all other 
times. 

It should be noted that a pointer accompanying active structure Type 1 has the same 
*£XZ5utoBB the pointer in the existing ITU-T and ANSI standards i.e., it indicates 
the number of octets between it and the beginning of the next structure. 



4.3. RECEIVER 

(R) The receiving CES IWF Shall calculate the length of the payload/signaling 
( ' eubrt^S^ from the value of the bitmask which is located at the beginning of 
payload of active structure Type 1 . 
This calculation is performed by multiplying the number of active indication bits in the 
bit malk by 24 for DS1 and 16 for E1 and adding N/2 octets for signahng substructure 
for the case of CAS For the case of CCS or Basic Service, the structure payload s ze 
!s always the Tnumber o? active time slots. Note that the CCS time slot is included in the 
count if present in the subject structure. 
m\ The calculated lenqth Shall be used as the length of all subsequent type 2 
( } i^rS^Sc^^hout bit mask) until the next bitmask (type 1 structure) 
is received. 

The new bitmask either verifies or changes the calculated length. 

Following the 4 time slot configured structure example and assuming all are active. 

the bit mask value indicates 4 active slots The payload 

ayoa fassumina DSD ie., 96. The s gnaling substructure length is 2 (following tne 
GAS ISSSSfo ^ the CES). Total plyload/signaling substructure length equals 98. 
The same example for CCS yields a payload/signaling size of 4 Octets. 
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(R) The receiver Shall identify the beginning of the payload/signaling substructure 
at M octets after the beginning of the Type 1 active structure which is identified 
by the pointer. M is equal to the number of octets in the bitmask. 

Notice this rule results from the fact that the pointer (in type 1 structures) points to the 
beginning of the total structure which always starts with the bitmask. In the 4 time slot 
example, M = 1 . Therefore, the payload/signaling substructure starts one octet after 
the beginning of the type 1 structure. 

In the Type 2 active structures the beginning of the payload/signaling substructure is at 
the beginning of the entire structure because there is no bitmask. 

4.4 All Time Slots INACTIVE 

This section addresses transition between states of one or more active time slots to all 
inactive time slots and vice versa. 

4.4.1 Transition From Active to ALL Inactive 

When all assigned time slots transition from at least one active to all inactive, the 
following requirements apply. 

(R) Upon the detection of all time slots being inactive, the transmitter Shall send 
an Inactive Structure (see Section 3.3) following the first pointer after detecting 
the all inactive state. The last cell containing active structure Shall be 
completely transmitted at the active structure rate before reducing the rate to 
the inactive structure rate. 

(R) The transmitter Shall continue to transmit cells containing the Inactive Structure 
at a cell rate greater than one cell every 0.5 second. This is to insure that a 
LOC state is not declared 

(R) The IWF receiver, receiving cells meeting the previous requirement, Shall 
cause the IWF to transmit idle code in the time slots of the receiving DS1/E1 
line associated to the subject VC. The specific code Shall be user 
programmable. Otherwise, the receiver may indicate LOC and the IWF sends 
AIS on the receiving DS1/E1 line. 

4.4.2 Transition From ALL Inactive to Active Time Slot(s) 

(R) Upon detection one or more time slots becoming active, the transmitter Shall 
send a Type 1 Active Structure following the last Inactive Structure. The time 
lapse between detecting a time slot becoming active and transmission of the 
first cell containing this slot's information Shall not exceed 50 ms. 

(R) The receiver Shall detect the transition to active status by detecting a valid non- 
zero bit mask following the all zero bit masks (Inactive Structures) it has been 
receiving during the idle period. Upon detecting this state, the receiver Shall 
interpret the associated structure as a Type 1 Active Structure and begin 
reassembling the active slots data and sending it on the correlating time slots 
in the receiving DS1/E1 line. 
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5. ATM VIRTUAL CHANNEL REQUIREMENTS 

The subsections that follow specify traffic parameters and tolerances as defined in A.6 
of the UNI 3.1 Specification. 

The requirements described in this section must be met by the ATM network that 
provides an end-to-end ATM connection, i.e., from the input ATM Interface to the output 
ATM Interface in Figure 5.1. 



ATM Interface 



ATM Interface 



\ 



DBCES 
Inter- 
working 
Function 



s 



ATM 
Network 



DBCES 
Inter- 
working 
Function 



Service Interface 



Service Interface 



Figure 5.1 : Reference Network Configuration 



(R) Quality of Service Class 1 for circuit emulation from the ATM Forum UNI 
Specification Version 3.1 Appendix A shall be used. 



5.1 TRAFFIC PARAMETERS AND TOLERANCES 

Traffic policing may be performed on cells generated by the DBCES Interworking 
Function and transported by the ATM network. 

The CDV Tolerance parameter of the UPC should take into account any cell delay 
variation caused by the introduction of OAM cells. The CDV Tolerance should also 
account for any CDV that occurs in the intervening multiplexing and switching devices 
between the Interworking Function and the UPC device. 

In the context of this specification, CDV Tolerance is considered a network option, and 
is currently not subject to standardization. 

The following sections give the Peak Cell Rate (PCR) for various versions of the 
DBCES Interworking Function. 

In all cases, if the OAM traffic is to be included in the PCR per -UNI I 3.1 section 
3.6.3.2.3.7, then the OAM traffic parameter cells needs to be added to the above or 
specified separately. 
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5.1.1 DBCES Cell Rate 

This section provides guidelines for the calculation of the Peak Cell Rate (PCR) for 
CLP=0+1 DBCES ATM connections. Note that these guidelines provide a maximum 
PCR estimate. The actual cell rate at any given time will depend upon the number of 
active channels in the encoded AAL1 structures. In order to develop the following 
estimates, it is assumed that all channels served by the DBCES IWF are active. 

In addition, the following calculations assume that a bit mask substructure is sent once 
in every eight cells and, correspondingly, that an AAL1 structure pointer is also 
encoded once in every eight cells. 

Note that for very large structures, the actual bitmask may not actually be sent every 
eight cells. For example, when using DS1 with 24 channels active the payload 
substructure will be 576 octets in length (24 channels times 24 frames per 
Superframe). The CAS signaling substructure (assuming CAS support) would add 
another 12 octets and the bitmask itself would add another three octets. The active 
structure with bitmask would then be 591 octets long. Assuming an AAL1 pointer every 
8 cells (as noted above), this would result in around 12.6 cells generated per AAL1 
structure. In this case, the bitmask would only be sent once every 12 or thirteen cells - 
even though an AAL1 structure pointer field would be inserted every eight cells. The 
bitmask substructure would be inserted only after a pointer indicating an actual 
beginning of a new structure (pointer value from 0 through 95). When the structure 
pointer value is equal to 127, indicating no new AAL1 structure begins in the next two 
cells, then no bitmask substructure could begin in the next two cells. 



But for purposes of the following calculations, it is assumed that a bitmask IS sent once 
for every AAL1 structure pointer field insertion every eight cells. Consequently, the 
calculation will be a slight over estimate for large structure sizes (DS1 configurations 
with more than 15 channels configured or E1 configurations with more than 23 
channels without CAS or 22 channels with CAS configured). In the worst case, though, 
this over estimate is only by about 0.25 percent when AAL1 structure pointers are sent 
once every eight cells. (This over estimate increases, however, when AAL1 structure 
pointers are sent once every four or two cells). The formula to generate the more 
accurate estimate would be much more complicated - and probably not worth the 
complexity for the amount of over estimate involved. The more ambitious implementors 
may choose, however, to determine a calculation that takes this into account, in order 
to eliminate this over estimation. 

5.1.1.1 Basic Service 

Basic Service here refers to DBCES service without CAS signaling. In this service, for 
example, the encoded AAL1 structures do not include the signaling substructure and 
the payload structure is only 1 frame of channel samples in length (as opposed to a full 
multiframe of samples for the CAS modes). 

Note that AAL1 structure pointers will be utilized for all DBCES connections, even 
when the number of configured channels is equal to one. (The CES specification 
defines that the N=1 case in basic service mode would not use pointers.) This is 
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required by the DBCES IWF in order to allow the indication of an active structure with 
bitmask once every eight cells, even when N is equal to one. 

(R) If partial cell fill is not used, the PCR on CLP=0 + 1 required for AAL1 transport of 
Nx64 kbps DBCES Basic Service is 

|(8000 x N) / {46.875 - [0.125 x ( 1 + INT (N/8) )]}| cells per second 

Where: INT means Integer number resulting from dividing N by 8 

|x| means "smallest integer greater than or equal to x". If partial cell fill is used, 

the PCR is 

|(8000 x N) / {K - [0.125 x ( 1 + INT (N/8) )]}| cells per second 
where K is the number of AAL-user octets filled per cell. 
Both of these are derived by dividing the required user payload structure octet- 
rate by the number of payload structure octets carried per cell. 

5.1.1.2 DS1/E1 Service w/CAS 

(R) The PCR on CLP=0+1 required for AAL1 transport of E1 DBCES Service 
w/CAS is: 

1. No partial cell fill, N even: 

|8000 x [ NX33/32 ] / {46.875 - [0.125 x ( 1 + INT (N/8) )]}| 

2 ? No partial cell fill, N odd: 

|8000 x [ (1 + Nx33) / 32 ] / {46.875 - [0.1 25 x ( 1 + INT (N/8) )]}| 

3. Partial cell fill, N even, K the number of AAL1 -user octets 
filled: 

|8000 x [ NX33/32 ] / {K - [0.125 x ( 1 + INT (N/8) )]}| 

4. Partial cell fill, N odd, K the number of AAL1 -user octets filled: 
|8000 x [ ( 1 + Nx33 ) / 32 ] / {K - [0.1 25 x ( 1 + INT (N/8) )]}| 
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(R) The PCR on CLP=0+1 required for AAL1 transport of DS1 Nx64 Service 
w/CAS is: 

1. No partial cell fill, N even: 

|8000 x [ NX49/48 ] / {46.875 - [0.125 x ( 1 + INT (N/8) )]}| 

2. No partial cell fill, N odd: 

|8000 x [ (1 + Nx49) / 48 ] / {46.875 - [0.125 x ( 1 + INT (N/8) )]}| 

3. Partial cell fill, N even, K the number of AAL1-user octets 
filled: 

|8000 x [ Nx49/48 ] / {K - [0.1 25 x ( 1 + INT (N/8) )]}| 

4. Partial cell fill, N odd, K the number of AAL1 -user octets filled: 
|8000 x [ (1 + Nx49) / 48 ] / {K - [0.125 x ( 1 + INT (N/8) )]}| 

These rates are derived by dividing the effective user payload plus signaling 
substructure octet-rate by the number of user payload plus signaling substructure 
octets carried per cell. 

Because all of the signaling bits are grouped together at the end of the AAL1 
structure, virtual channels supporting DS1 and E1 DBCES Service with CAS 
support will suffer some jitter in cell emission time. For example, an IWF carrying 
a DBCES E1 circuit with N=30 and CAS enabled will, on average, emit about 
10.5 cells spaced by 191.8 msec, followed by a cell carrying CAS bits after a gap 
of only 130 msec. This jitter in cell emission time must be accommodated by 
peak-rate traffic policing function. 
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5.2 ATM VIRTUAL CHANNEL PAYLOAD TYPE AND CLP 

Sections 3 3 and 3 4 of the UNI 3.1 document specify that, in addition to Virtual Circuit 
an5 Virtual Path .fields the ATM cell header contains the Cell Loss Pr.or.ty b.t and the 
three-bit Payload Type Identifier field. 

5.2.1 Cell Loss Priority (CLP) 

(R) At the sender, this bit shall be set to "0". At the receiver, this bit shall be 
ignored. 

5.2.2 Payload Type Identifier 

(R) All cells carrying emulated circuit data shall be sent with the Payload Type 
( ' Identifer fieTd set to 000, indicating "User Data cell, congestion not 

experienced, SDU-type=0". 
(R) All four User Data cell Payload Type Identifier values (000, 001, 010 and 011) 

shall be accepted by the receiver. 

5.3 IMPAIRMENTS 

Some additional information on ATM Virtual Channel impairments can be found in 
section 5.3 of af-vtoa-0078.000 (CES V2.0 Specification). 

6. SIGNALING 

The UNI 3 1 SVC support is Optional for the DBCES IWF. The following sections are 
applicable only when such SVC support is provided. 

This section specifies ATM UNI 3.1 signaling between thermal support DBCES. 
There is no mapping specified between signaling that pertains to traditional DS1, E1 
and Nx64 Services and ATM UNI 3.1 signaling. 

^^^^^ 

other signaling messages. 

6.1 ADDRESSES AND IDENTIFIERS FOR DBCES SWITCHED VIRTUAL 
CHANNELS (SVCS) 

All DBCES SVCs are point-to-point. As with all SVCs, the endpoints must be identified 

fflW w— n^U) Informal eiemen, (IE) distinguish .he 
particular type of DBCES SVC being set up. 
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6.2 SETUP MESSAGE CONTENTS 

Section 5.3.1.7 in the UNI 3.1 Specification lists the mandatory and optional 
information elements in the SETUP message. This DBCES specification places 
constraints on the values of certain fields in the following mandatory information 
elements: 

1 . ATM Traffic Descriptor 

2. Broadband bearer capability 

3. QoS Parameter 

The following sections describe those constraints. 

The following information elements (which in general are optional) are required for 
DBCES signaling: 

1. The AAL Parameters Information Element 

2. The Broadband Low Layer Information Element 

The required contents of these information elements are discussed in the following 
sections. 

The other information elements identified in UNI 3.1 Section 5.3.1.7 as optional remain 
optional for DBCES SVCs; this DBCES specification places no constraints on the 
values of the fields in these optional information elements. 

Note that in the following sections we have omitted the fixed information element 
header fields and field identifiers from this specification; these should be inserted in 
the appropriate place in the information element. 

6.2.1 ATM Traffic Descriptor 

For DBCES SVCs, the following two fields in this information element must be 
specified: 

1. Forward peak cell rate CLP=0+1 

2. Backward peak cell rate CLP=0+1 

The values for these fields should be calculated as specified in Section 5.1 . 

The Best Effort Indicator and the Traffic Management Options Identifier must be 
omitted. We recommend that the other fields be omitted as well. 
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6.2.2 Broadband Bearer Capability 

The following table specifies the values for the fields in this information element. 



| Field 


Value | 


Bearer Class 


'1000 0' BCOB-X 


Traffic Type 


'001' Constant bit rate 


Timing Requirements 


'01' End-to-end timing required 


Susceptibility to clipping 


'00' Not susceptible to clipping 


User Plane Connection Configuration 


f 00' Point-to-point 



Table 6.1: Broadband Bearer Capability IE Field Values for DBCES SVCs 



6.2.3 Quality of Service Parameter 

The following table specifies the values for the fields in this information element. 



I Field 


Value | 


QoS Class Forward 


'0000 0001' QoS Class 1 


QoS Class Backward 


'0000 0001' QoS Class 1 



Table 6.2: QoS Parameter IE Field Values for DBCES SVCs 



The Coding Standard field in this Information Element shall be coded as "11" when 
operating over ATM Forum compliant networks. However, when interfacing to an ITU 
conformant network that is not ATM Forum compliant, the Coding Standard shall be 
coded "00" and the QoS Class Forward and QoS Class Backward are each coded 
"0000 0000", meaning QoS Class 0 — Unspecified QoS Class. 
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6.2.4 ATM Adaptation Layer Parameters 

The following table specifies the AAL Parameters field values for DBCES Service. If 
the called party does not accept these parameters, it should release the call with 
cause 93 (AAL Parameters not Supported). 



Field 


Value 


aal lype 


'nnnn nnni' AAI Tvnp 1 


Subtype 


'0000 0010' Circuit Transport 


CBR rate 


'0000 0001' 64 kbit/s 
'0100 0000' Nx64 kbit/s, N>1 


Multiplier 


The value 'N' for Nx64 kbit/s. Omit 
field for 64 kbit/s case. 


Structured Data Transfer Blocksize 


Size in octets, as defined in Section 3 


Partially filled cells method 


K, the number of AAL-user octets 
filled per cell; see Section 3. Omit 
field if partial cell fill is not used 



Table 6.3: AAL Parameters IE Field Values for DBCES Service SVCs 



6.2.5 Broadband Low Layer Information 

This information element identifies that the signaling entities are ATM Forum DBCES 
AAL User Entities as specified in this DBCES specification. It also identifies the 
specific service and coding approach for DBCES Service. 



Field 



Value 



User Information Layer 3 Protocol 
(octet 7) 


'01011' ISO/IEC TR 9577 


ISO/IEC TR 9577 Initial Protocol Identifier 
(IPI) 

(octet 7a, 7b) 


IPI is coded '1000 0000' to indicate 
IEEE 802.1 SNAP identifier. Hence, 
octets 7a and 7b are coded as '0100 
0000' and '0000 0000', respectively. 


Organizational Unit Identifier (OUI) 
(octets 8.1-8.3) 


x'OO AO 3E' ATM Forum OUI 


Protocol Identifier (PID) 
(octets 8.4-8.5) 


x'0011' DS1/E1 DBCES Basic 
Service 


x'0012' E1 DBCES Service w/CAS 


x'0013' DS1 SF DBCES Service 
w/CAS 


x'0014' DS1 ESF DBCES Service 
w/CAS 



Table 6.4: Broadband Low Layer Information IE Field Values for DBCES SVCs 
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7. CALL INITIATION PROCEDURES 

nntinnai Drocedures for the automatic initiation of an SVC between two DBCES 
^■SS^u^ via this s Pfcifica^ 

procedures, please refer to section 7 of af-vtoa-0078.000 (CES V2.0 Specification). 

8. MANAGEMENT 

The SNMPV2 Network Management interface to the DB iCES IWF will be Provide^ 
the CES V2.0 MIB, as described in section 8 of af-vtoa-0078.000. This Otb v^.u mid 
will apply, with the following exceptions: 

The CESCbrService object need not be supported, since this DBCES 
solcificlor only supports structured mode. (Unstructured service is not 
dSflSdwKln *te specification since Nx64 kbps service can only be supported 
in structured mode.) 

- The CESCbrClockMode object need not bej supported sir «»«agured mode 
requires the use of synchronous timing - as in the CES V2.0 specification. 

- The j2Cas value for the CESCas object should not be used since this 
splcificafen does not specify J2 (Japanese 6.312 Mbps interfaces) support. 

- The buffer underflow counter Shall increment only if active time slots within a 
VC run out of data. Active time slots, for this purpose, are determined by the 
last received valid Bitmask. 

- The buffer overflow counter Shall increment when the first time slot within i a , VC 
overflows Any additional overflow Shall not be counted until all active time 
slots exit the overflow state. 

Note that a management interface for an idle detection mechanism may also need to 
to^^^SX^the definition of the idle detection mechanism is not de ined 
IKS T'sDecrfication but is left as an implementation dependent item. 
wI^^^MIB^ private MIB extension) may be necessary to provide 
the management interface for the implemented mechanism. 
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ANNEX A 

IDLE (INACTIVE) DETECTION MECHANISMS 

This annex is Informative Only and is intended in providing guidance to implementors 
for the proper detection of time slot activity status which is required to determine the 
size of the active structure. 

A.1. Introduction 

It is essential to be able to detect the idle status of each of the time slots to meet the 
requirements of this specification. This annex discusses two methods for detecting the 
activity status of any given time slot. The first is based on utilizing the AB signaling bits 
in a CAS type slot. The second is based on identifying a recurring idle code pattern, 
for a specified interval, in the information content of the time slot. There may be 
additional methods beyond these two. Using one of the following methods or any 
other not discussed in this document is at the option of the implementor. As stated 
above, this entire annex is Informative. 



A. 2. Idle Detection Utilizing Idle Code Pattern 

The idle status of a time slot can be detected (at the transmitting IWF) by detecting the 
continuous occurrence of an idle code pattern in that time slot's data for some 
specified interval. This section addresses the requirements for detecting this idle 
status. 

A. 2.1 Data Pattern Matching Requirements 

To detect the idle status of a time slot on a given connection, the data content of this 
time slot must be matched against a pre-defined idle code pattern or patterns and this 
matching must be integrated for a specified interval. 

The idle code pattern(s) against which the time slot data is matched must be 
configurable. A typical idle code pattern for voice connections, for example, would be 
7F or FF hex. Other connections, DDS data connections for example, often use 
alternative patterns to indicate an idle (or "out of service") channel. Therefore, this idle 
code configurability will allow for this mechanism to be used on a wide variety of circuit 
types. 

It should also be possible to match the time slot data against one of a minimal set of 
data patterns, i.e., if the slot's data content matches any of the patterns, it is considered 
idle. The maximum number of allowed patterns for any single time slot should be 
between 2 and 6. Often a different pattern is used to distinguish between an "idle" 
channel and an "unequipped" channel. Voice circuits, for example, typically apply a 
continuous 7F hex code for "idle" channels, but apply a continuous FF hex code for 
"unequipped" channels. Data circuits, on the other hand, may utilize a selection of 
alternative codes to indicate "why" a circuit might be out of service. But in most of 
these cases, the actual connection bandwidth could be released during this 
"idle/unequipped/out-of-service" interval. By making the specific codes to be 
recognized as well as the number of such codes configurable, a wide variety of 
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connection types can be accommodated. A ^SS^ffSS * ™ * *" 

allowed patterns would be required in order to detect an idle state. 

It may be desirable for the receiving IWF to "latch" the last data pattern receive^ fora 

sDecffic time slot before it goes inactive so that it can continue to play out that same 

SSJ^dtrinTthe time'that the circuit remains J™*^ 

the receivinq end to maintain the same idle data pattern as detected at the transmitting 

e'd T^s is particular^ useful in cases where the ^T^!^.^^. 
pattern itself to determine the specific state of the circuit, i.e., whether it is idle or out 

of-service" for example. 

A 2.2 Integration Period Requirements 

The topttto to recognized as "idle" data patterns are not necessar, ly 
u^que" 

onlv their "continuous" occurrence which indicates the true idle state mis 
SegrS wil?be used to confirm a "continuous" pattern occurrence - and therefore a 
true "idle" state. 

,t is recommended that this integration period 

orovide an increased level of confidence in idle state detection 9"^.^"^*"'^ 
cc Z I possiSy maintain a more constant data code for longer periods of time in normal 

service. 

A default integration period of one second is suggested. Longer integration periods 
are left to the choice of user, but shorter is not recommended. 

For voice connections, an integration interval of ™ c r h ^^ an 
unnecessarilv lonq, as such a continuous occurrence of the «ie coae panem on c*m 
S votc^ ciSwould be extremely rare. Even yf^S^'^M 
silent but circuit is still active) typically ^^.^^^^ n ^^Z 
significant 3 or 4 data bits as well as the most significant bit (the sign bit) due to 

background noise. 

For digital data connections, it may be desirable for this integration period to be more 
than 1 second. 

necessary, however, for E1 CAS signaling systems and circuits for these systems 
could be configured to match all data bits. 

It is anticipated that only a very short integration interval would be required for the 
d^tec^oTadrcSwrnlng "out" of idle - perhaps only two to four frames (i.e. 250 to 
So^S^nS The circuit would be declared active upon the first occurrence of 
?his miS^^^ samples NOT containing the idle code pattern previously 
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recognized. This minimal integration would eliminate the possibility of occasional data 
pattern bit errors causing an idle circuit to be erroneously interpreted to have gone 
active. 

A. 3. Idle Detection Using AB Signaling Bits in CAS 

This section defines a recommended approach to detecting the activity status of a time 
slot using the AB bits of the Channel Associated Signaling. 

A. 3.1 Signaling Types 

To accommodate the multiple types of signaling which are encountered in different 
types of voice transmission equipment and maintain consistent implementations, the 
following recommendation appears to be the most sensible: The Value of the AB Bits 
used to determine the idle status of the time slots on a given connection should be 
user configurable. This allows the IWFs user to configure the values on the basis of 
the supported terminal equipment, and match the values on the two sides of the virtual 
connection. 

A. 3.2 Signaling Bits Interpretation for Different Types of Signaling 

This subsection helps implementors in configuring the AB bit values indicated in 
Section A.3.1 above. 

The following idle state recognition mapping utilizes only the A and B signaling bits. 
The C and D signaling bits are often used for echo canceler control, billing metering 
pulses, and so forth. These two bits (C&D) are rarely, if ever, used for signaling call 
activity/idle state indications. 

Table A.1 defines the patterns used in the majority of applications that the Circuit 
Emulation Service is likely to support. There are potentially some other applications 
which may not be covered by the table. There is no problem in accommodating such 
applications since the idle pattern is user configurable. 
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Signaling Type 


T1/E1 
Transmit 


T1/E1 
Receive 


A 


B 


A 


B 


E&M / PLAR 


0 


* 


0 


* 


FXU - Loop oian 


* 


1 


0 


* 


FXS - Loop Start 


0 


* 


* 


1 


FXO - Ground Start 


1 


* ** 
i 


0 


1 


FXS - Ground Start 


0 


1 


1 


* ** 
j 


R2 


1 


0 


1 


0 *** 




Table A.1: Idle State Patterns 

This table defines the states of the A and B signaling bits in the transmit and foe 

emulation of such a circuit to remain active is left for further study, 
state as well, but this is left for further study. 

idle state. 
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A.3.3 Integration Period 

An integration period over which the inactive state must be consistent is required. This 
is true because in many cases the signaling indicate a temporary idle (while the 
connection is still up) used for special indications such as wink pulses. 

An integration period of 1 Second or more is recommended. This is based on the fact 
that less than one second would result in false indications and much more than one 
second may be unnecessarily long. Integration period should be user programmable. 



ANNEX B 
ACRONYMS 

AAL ATM Adaptation Layer 

AAL1 ATM Adaptation Layer Type 1 

ATM Asynchronous Transfer Mode 

ATMF ATM Forum 

BISDN Broadband Integrated Services Digital Network 

B-LLI Broadband Low Layer Information 

CAS Channel Associated Signaling 

CBR Constant Bit Rate 

CCS Common Channel Signaling 

CDV Cell Delay Variation 

CES Circuit Emulation Service 

CLP Cell Loss Priority 

DBCES Dynamic Bandwidth Circuit Emulation Service 

DBU Dynamic Bandwidth Utilization 

DSO Digital Signal Level 0 (64 kbit/s) 

DS1 Digital Signal Level 1 (1544 kbit/s) 

DSS Dynamic Structure Sizing 

E1 Special digital trunk, European (2048 kbit/s) 

ESF Extended Super Frame 

IE Information Element 

IEC International Electrotechnical Commission 

IPI Initial Protocol Identifier 

ISDN Integrated Services Digital Network 

ISO International Organization for Standardization 

ATM Forum Technical Committee 25 



af-vtoa-0085.000 



pecifications of DBCES 



IWF Inter-Working Function 

J2 Japanese standard for 6.31 2 Mbit/s electrical PDH transmiss.on 

kbit/s, Thousand bits per second 
kbps 

LOS Loss of Signal 

LSB Least Significant Bit 

Mbit/s, Million bits per second 
Mbps 

MIB Management Information Base 

MSB Most Significant Bit 

p,sec microsecond 

OAM Operations and Maintenance 

OUI Organizational Unit Identifier 

PCR Peak Cell Rate 

PID Protocol Identifier 

PVC Permanent Virtual Circuit 

QoS Quality of Service 

SDU Service Data Unit 

SF Super Frame 

SNAP Sub-Network Access Protocol 

SNMP Simple Network Management Protocol 

SVC Switched Virtual Circuit 

TDM Time Division Multiplex 

UBR Unspecified Bit Rate 

UNI User to Network Interface 

UPC Usage Parameter Control 

VC Virtual Channel 

VCC Virtual Channel Connection 



End of DBCES specifications 
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